Quick heads-up: I have now filed FB10014020 on this issue.

You’re assuming that this problem is TCC related, but that’s not guaranteed. It could be that something else in the Accessibility subsystem has fallen over and that’s why you’re seeing these failures. Unfortunately I don’t know enough about these components to offer any alternative theories that you could reasonably test. Good point, I did not think of that! Unfortunately, I am also unsure about how to best test that theory. Given that I'm checking and rechecking the app in system preferences sometimes seems to help, though, I find it likely that this somehow has to do with TCC. Oh, I have one other trick up my sleeve here (-: It’s possible that a bunch of your users are seeing this problem and not reporting it to you. Speaking personally, if I see a weird problem like this and it’s cleared by a restart, I wouldn’t bother the app developer. However, there may be something you could do to improve that. AFAICT you could reasonably write code to detect this problem. That is, if AXIsProcessTrusted returns true and you’re not seeing window titles for, say, the Finder, you know you’re in this bogus state. If so, you could do this detection and specifically prompt the user to trigger a sysdiagnose log and get in touch. Depending on the size and expertise of your user base you may not want to add this to your release version; in that case, you might consider adding it to the version you ship to your beta testers. Thank you for the suggestion! I have indeed been collecting analytics and just the way you described for a couple of weeks, and it seems like a substantial portion of my user base is affected; large enough that I wouldn't want to notify them all (although random sampling might help with that). My group of beta testers on the other hand might be too small to solicit feedback, I fear. I'll need to think more about how I handle that. Another question related to this: Do you know of a good way to determine whether a given app mattress a particular designated requirement? I know that I can extract the designated requirement using codesign -d -r-, but am unsure of how to test a given requirement. I'm thinking of spctl, but am unsure of the appropriate syntax.

Thank you for the quick reply, Quinn! For updates, I am using Sparkle, which should perform the updates atomically (see https://github.com/sparkle-project/Sparkle/blob/acc4674c3e769c64434fec958d8ee0a397bfa6c7/Autoupdate/SUPlainInstaller.m#L210). My app is also distributed through Setapp; I am not sure how Setapp updates applications but I would expect them to do it correctly, and the problem occurs there as well. I will ask the next users who report this issue to provide a sysdiagnose. In the meantime, do any other problems come to mind for you that I could check for? What particularly surprises me is that a) AXIsProcessTrusted still returns true and b) the app still seems to be able to send Apple Events, even though those are protected by TCC as well.

Setting the scroll view's automaticallyAdjustsContentInsets property to false solved my problem.

Update: With the instructions in this StackOverflow article - https://stackoverflow.com/a/37902023/153354, I was able to at least change the app's display name in the "Notifications" System Preferences. After a reboot, the desired localized app name also shows up in notification titles. Note that this also shows the app's name in the Finder, but it does not change the actual file path to the application bundle. This is fine for my use case (a helper app with a fixed path that I want to present under a more user-friendly name).

We are seeing the same issues with UNUserNotificationCenter. This is exacerbated by the fact that macOS 11 display's the sending app's name prominently in each notification, much more visibly than before.